home *** CD-ROM | disk | FTP | other *** search
/ Cream of the Crop 1 / Cream of the Crop 1.iso / PROGRAM / TP060792.ARJ / 06-07-92.TPC
Text File  |  1992-06-07  |  42KB  |  1,195 lines
  1.  
  2. ▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄
  3.  
  4. Conference 4
  5. Date       01-01-00 00:00:00
  6. From       
  7. To         
  8. Subject    
  9.  
  10.  
  11. --- WM v2.01/92-0100
  12.  * Origin: A.C.E. of Spades (615)383-4381 The B.A.N. board (1:116/33)
  13.  * Tossed by SFToss v1.00b on 92/04/09  12:01:00
  14.  
  15. ▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄
  16.  
  17. Conference 4
  18. Date       05-31-92 20:26:05
  19. From       Trevor Carlsen
  20. To         Mark Ouellet
  21. Subject    Abbreviations
  22.  
  23.  
  24.  
  25.  SP> A list.. Welp, I M searching 4 1 4 about a year or so..
  26.  JM>>     Not to be too annoying (TC? Don't slay me here), but
  27.  JM>>isn't the official language of this echo English?
  28.  DP> I talk Eng., these r abbriviations, makes the msg "Shorter".. 
  29.  
  30.  MO>         Wrong, these make D messages "Harder" 2 read for us.
  31.  
  32. Mark I wouldn't let it worry you.  If the language is pseudo English, the
  33. message is on-topic and not against any of the rules, I ignore the stupidity
  34. of such a practice.  I certainly would never consider answering someone who
  35. is so illiterate, or so lazy, to use such inanities.  I don't believe anyone
  36. of a reasonable level of intelligence would use this type of thing.
  37.  
  38. We will drop the subject.
  39.  
  40. TeeCee
  41.  
  42.  
  43. --- TC-ED   v2.01  
  44.  * Origin: The Pilbara's Pascal Centre (+61 91 732930) (3:690/644)
  45.  * Tossed by SFToss v1.00b on 92/05/31  15:39:55
  46.  
  47. ▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄
  48.  
  49. Conference 4
  50. Date       05-31-92 13:47:29
  51. From       Mark Ouellet
  52. To         Jud Mccranie
  53. Subject    Re: Impact Of .Tpu Size O
  54.  
  55.  
  56.     On 27 May 92, you, Jud Mccranie, of 1:3645/10.0 wrote...
  57.  
  58.  MO>>         That's because the CRT INIT routine will reference
  59.  MO>> variables and procedures which are then kept by the linker.
  60.  MO>>
  61.  MO>>         Remember using CRT installs video routines which
  62.  MO>> handle screen writes, those same routines you showed people
  63.  MO>> how to bypass to write ANSI screens.
  64.  
  65.  JM> That wasn't me.
  66.  JM> 
  67.  MO>>         So naturely, anything used must be kept by the
  68.  MO>> linker but try using other routines such as WRITE and
  69.  MO>> WRITELN and GOTOXY etc... you'll see they were discarded
  70.  MO>> when you first compiled without using them.
  71.  
  72. Jud,
  73.         Allow me to refresh your memory ;-)
  74.  
  75. >Area : Pascal Intl 50000+ Received
  76. >From : Mark Ouellet                        23-May-92 22:15:56
  77. >To   : Jud Mccranie                        23-May-92 22:15:56
  78. >Subj.: Re: Impact Of .Tpu Size O
  79. >
  80. >    On 18 May 92, you, Jud Mccranie, of 1:3645/10.0 wrote...
  81. >
  82. > GS>> If you RTFM, you'll see that it's "smart" linker throws out the
  83. > GS>> code which isn't used.
  84. >
  85. > JM> Not so with the CRT unit.  Just add it to USES and it will increase the
  86.  
  87. > JM> size of the EXE, even if you don't use anything in the CRT unit.
  88. >
  89. >Jud,
  90. >        That's because the CRT INIT routine will reference
  91. >variables and procedures which are then kept by the linker.
  92. >
  93. >        Remember using CRT installs video routines which
  94. >handle screen writes, those same routines you showed people
  95. >how to bypass to write ANSI screens.
  96. >
  97. >        So naturely, anything used must be kept by the
  98. >linker but try using other routines such as WRITE and
  99. >WRITELN and GOTOXY etc... you'll see they were discarded
  100. >when you first compiled without using them.
  101. >
  102. >        Best regards,
  103. >        Mark Ouellet.
  104. >
  105. >--- ME2
  106. > # Origin: One BEER gets me drunk.... usualy the 47th ;-) (Fidonet 1:240/1.4)
  107.  
  108.         And if that ain't enough, I still have the original
  109. message to which that reply was sent as well as the 50,000+
  110. messages before that ;-)
  111.  
  112.         Anyways, as you can plainly see you DID write that
  113. message and my reply was intended to remind you that the CRT
  114. initialized some constants and video related routines so the
  115. smart linker can't ignore that.
  116.  
  117.         Best regards,
  118.         Mark Ouellet.
  119.  
  120.  
  121.  
  122. --- ME2
  123.  * Origin: Buy ANY Seagate HD, get FREE Humidifier he he!!!(Fidonet 1:240/1.4)
  124.  * Tossed by SFToss v1.00b on 92/06/01  12:51:47
  125.  
  126. ▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄
  127.  
  128. Conference 4
  129. Date       05-31-92 13:56:05
  130. From       Mark Ouellet
  131. To         Sean Ocker
  132. Subject    Re: SBlaster...
  133.  
  134.  
  135.     On 26 May 92, you, Sean Ocker, of 1117/369.0 wrote...
  136.  
  137.  SO> Sorry I max out at 2400, but allow freqs from anyone at up to 4 hours.
  138.  
  139.         Yes your BBS is a 2400 but isn't there a BBS using
  140. 9600 HST near you, one that doesn't cost you anything to
  141. post there but that would still allow me to picj up the
  142. stuff.
  143.  
  144.         I would prefer FREQing the stuff. Much faster than
  145. snail-mail. ;-)
  146.  
  147.  SO> # Origin: While Parole_Board do begin num:=1117/369;
  148.                                               ^^^^^^^^^^^
  149. BTW Sean,
  150. some mailers seem to have troubles with your adress,
  151.  
  152.         IS IT     1117/369
  153.         or is it 1:117/369
  154.  
  155. I think the way it is noted in your origin line is the
  156. problem.
  157.  
  158.         Best regards,
  159.         Mark Ouellet.
  160.  
  161.  
  162.  
  163. --- ME2
  164.  * Origin: Buy ANY Seagate HD, get FREE Humidifier he he!!! (Fidonet 1:240/1.4)
  165.  * Tossed by SFToss v1.00b on 92/06/01  12:51:47
  166.  
  167. ▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄
  168.  
  169. Conference 4
  170. Date       05-31-92 14:01:54
  171. From       Mark Ouellet
  172. To         Vince Laurent
  173. Subject    Re: Programming Adlib/Soundblaster [5/6]
  174.  
  175.  
  176.     On 26 May 92, you, Vince Laurent, of 1:382/10.0 wrote...
  177.  
  178.  VL>>> I got 1,2, and 5 but where are 3,4, and 6?
  179.  
  180.  |=>>   Vince,
  181.  |=>>           The original posting was missing 2,3 and 5, we only
  182.  |=>>   got 1,4 & 6 so we now got #1 twice but are still missing #3.
  183.  
  184.  |=>>   So far we got 1, 2, 4, 5, 6. [Just in case I managed to lose
  185.  |=>>   you in the first paragraph ;-) ]
  186.  
  187.  VL> OK...so who ever gets a complete package first send it to the other, OK?
  188.  
  189.  
  190. Vince,
  191.         Ok, when, if I get them before you I'll send them to
  192. 382/10.
  193.  
  194.         Did you catch Lars's last post, he posted the whole
  195. thing in 3 messages this time and they all made it here
  196. without any problem, have you got them ??? If not I'll send
  197. them to you.
  198.  
  199.         Best regards,
  200.         Mark Ouellet.
  201.  
  202. --- ME2
  203.  * Origin: Buy ANY Seagate HD, get FREE Humidifier he he!!!(Fidonet 1:240/1.4)
  204.  * Tossed by SFToss v1.00b on 92/06/01  12:51:47
  205.  
  206. ▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄
  207.  
  208. Conference 4
  209. Date       05-31-92 14:03:42
  210. From       Mark Ouellet
  211. To         Brad Roberts
  212. Subject    Re: SayGet Unit Test Program
  213.  
  214.  
  215.     On 25 May 92, you, Brad Roberts, of 1:382/52.0 wrote...
  216.  
  217.  BR> Program TestSayGet;
  218.  BR> 
  219.  BR> Uses
  220.  BR> Crt, SayGet;
  221.  
  222.  BR> AddGet ('String        :',SizeOf(Str1),10,15,15,GetString,LightGray,
  223.  
  224.  BR> ReadGets;
  225.  
  226.  BR> That is folks.. try it out.. its worked well for me, but then I'm not 
  227.  
  228.  BR> perfect.  If you have any trouble or suggestions, let me know.
  229.  
  230. Some stuff deleted.
  231.  
  232. Brad,
  233.         IT looks great and BTW, forget that message about
  234. missing #3-#8, they all made it this time around.
  235.  
  236.         You used the exact approach I had in mind except I
  237. wasn't fluent enough in OOP yet to build the project.
  238.  
  239. Very nice unit.
  240.  
  241.         Best regards,
  242.         Mark Ouellet.
  243.  
  244.  
  245.  
  246. --- ME2
  247.  * Origin: Buy ANY Seagate HD, get FREE Humidifier he he!!! (Fidonet 1:240/1.4)
  248.  * Tossed by SFToss v1.00b on 92/06/01  12:51:47
  249.  
  250. ▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄
  251.  
  252. Conference 4
  253. Date       05-31-92 23:35:09
  254. From       Mark Ouellet
  255. To         All
  256. Subject    Looking for SHAZAM (TV App. code gen.)
  257.  
  258.  
  259. Hi All,
  260.         Since I got no answer last time I'm asking again.
  261.  
  262.         I saw a file called SHAZAM on Turbo City which is
  263. supposed to be a Turbo Vision application generator. I
  264. assume it is like DLGDSN or MENUGEN.
  265.  
  266.         Now I can't download or Freq from Turbo City so if
  267. someone HAS SEEN or HAS this file available for Freq, from
  268. unlisted nodes (Points) could you please tell me where to
  269. get it.
  270.  
  271.         I assume since Turbo City has it, someone else is
  272. bound to have it also.
  273.  
  274.         Best regards,
  275.         Mark Ouellet.
  276.  
  277.  
  278.  
  279. --- ME2
  280.  * Origin: Governments, Proof of Peter's principle (Fidonet 1:240/1.4)
  281.  * Tossed by SFToss v1.00b on 92/06/01  12:51:47
  282.  
  283. ▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄
  284.  
  285. Conference 4
  286. Date       06-01-92 21:13:00
  287. From       Norbert Igl
  288. To         Max Maischein
  289. Subject    Detecting ANSI ? / INT 2Fh problems ??
  290.  
  291.  
  292.  
  293.  
  294.  >>   BTW... won't even work  with $2F this way, because Turbo's
  295.  >>   INTR() has problems with the $2F function!
  296.  
  297.  > Why, could you tell me more about this problem ??
  298.  > I've not used Intr a long time, especially since the BASM came out,
  299.  > but I'd like to know, what I'm missing !
  300.  
  301.    Sorry, i screwed something up.....
  302.  
  303.    There is no problem calling $2F with Intr(),
  304.    but there are *many* problems writing your own Int2F-Handler
  305.    without ASM/END or INLINE...
  306.    ( STACK, [BP] and related things, you know?)
  307.  
  308.    so i think, i get Off Topic discussing this DOS-behavior here.
  309.  
  310.    Bye from Germany, Norbert
  311.  
  312. --- FD 2.02/FastEcho
  313.  * Origin: Let's talk about hex, baby.... (2:241/5300.3)
  314.  * Tossed by SFToss v1.00b on 92/06/02  13:37:27
  315.  
  316. ▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄
  317.  
  318. Conference 4
  319. Date       06-01-92 01:01:07
  320. From       Mark Ouellet
  321. To         Stein-Ivar Johnsen
  322. Subject    Re: Looking for frequable SHAZAM
  323.  
  324.  
  325.     On 21 May 92, you, Stein-Ivar Johnsen, of 2:502/808.0 wrote...
  326.  
  327.  MO>>         I'm looking for this file SHAZAM which is a Turbo
  328.  MO>> Vision program generator.
  329.  MO>>         If any one has this file up for Freq, from unlisted
  330.  MO>> nodes, please let me know.
  331.  
  332.  SJ> You find it here as SHAZAM.ZIP  159750b
  333.  
  334. Stein-Ivar,
  335.         Thanks, I just sent another message about this and
  336. this (God sent reply) was amongst the mail I picked up in
  337. the process. Thanks again, I'm getting out of ME2 right
  338. after this to Freq the file.
  339.  
  340.         Best regards,
  341.         Mark Ouellet.
  342.  
  343.  
  344.  
  345. --- ME2
  346.  * Origin: Governements, Proof of Peter's principle (Fidonet 1:240/1.4)
  347.  * Tossed by SFToss v1.00b on 92/06/02  13:37:41
  348.  
  349. ▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄
  350.  
  351. Conference 4
  352. Date       06-02-92 00:37:48
  353. From       Trevor Carlsen
  354. To         Jud Mccranie
  355. Subject    Reading records
  356.  
  357.  
  358.  
  359.  JM> In TP, is there any good way to read records starting at a
  360.  JM> position in the file that is not a multiple of the record
  361.  JM> length?
  362.  
  363. I posted this on the 16th May.  Seems you never got it.
  364.  
  365.  
  366. {$I-}
  367. function ReadRec(var f;                        { The typed or untyped file }
  368.  
  369.                  RecNo : longint;{ The record number to read ( zero based) }
  370.  
  371.                  Offset: word;                    { The size of the header }
  372.  
  373.                  var Rec;{ The record to be read - untyped for convenience }
  374.  
  375.                  ErrCode: { I/O error code } integer): boolean;
  376.  
  377.   { Reads a record number from a file of typed records that has an odd size}
  378.   { header record. Returns true if read was OK.   (Requires the DOS unit)  }
  379.  
  380.  
  381.   var
  382.     OldSize,
  383.     result  : word;
  384.  
  385.   begin
  386.     with FileRec(f) do begin
  387.       OldSize := RecSize;                  { Save the declared record size }
  388.  
  389.       RecSize := 1;                  { Change to a single byte record size }
  390.  
  391.       seek(file(f),(RecNo * OldSize) + Offset);{ Seek to calculated offset }
  392.  
  393.       RecSize := OldSize;                        { Restore the record size }
  394.  
  395.       ErrCode := IOResult;                           { Check for I/O error }
  396.  
  397.       if ErrCode <> 0 then { an I/O error occurred }
  398.         ReadRec := false  
  399.       else { no I/O error } begin
  400.         BlockRead(file(f),Rec,1,result);            { Read a single record }
  401.  
  402.         ErrCode := IOResult;                         { Check for I/O error }
  403.  
  404.         ReadRec := (ErrCode = 0) and (result = 1);
  405.       end; { else }
  406.     end; { with }
  407.   end;  { ReadRec }
  408. {$I+}
  409.  
  410. To use, just open your file as a typed file of the type you need then to read
  411. record number RecordNumber -
  412.   
  413.   if not ReadRec(f,RecordNumber,HeaderSize,YourRecord,ErrorCode) then
  414.     writeln('I/O read error ',ErrorCode,' record number ',RecordNumber);
  415.  
  416.  
  417. TeeCee
  418.  
  419.  
  420. --- TC-ED   v2.01  
  421.  * Origin: The Pilbara's Pascal Centre (+61 91 732930) (3:690/644)
  422.  * Tossed by SFToss v1.00b on 92/06/02  19:32:07
  423.  
  424. ▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄
  425.  
  426. Conference 4
  427. Date       06-02-92 00:40:42
  428. From       Trevor Carlsen
  429. To         All
  430. Subject    Rules of this echo
  431.  
  432.  
  433.  
  434. Would all sysops please ensure that a copy of these rules is available
  435. to all users of the echo.  It suggested that they be made a protected
  436. message to ensure that normal message area housekeeping does not not
  437. result in them being deleted.
  438.  
  439. RULES OF THE PASCAL ECHO
  440.  
  441. The Pascal echo is an internationally distributed FidoNet echo devoted
  442. to the discussion and promotion of the Pascal programming language in
  443. all its variations.
  444.  
  445. MODERATOR.
  446.  
  447. The currently appointed Moderator is Trevor Carlsen. He can be reached
  448. by Netmail at 3:690/644 or by normal postage by writing to -
  449.  
  450.   Trevor J Carlsen
  451.   Post Office Box 568
  452.   Port Hedland 
  453.   Western Australia 6721  
  454.   Phone (voice) +61 91 73-2026  (Local time is GMT+8)
  455.         (data)  +61 91 73-2569
  456.  
  457. RULES.
  458.  
  459.  1. Leave moderation to the moderator. Self appointed "echo policemen"
  460.     only waste echo space and create ill-feeling.
  461.  
  462.  2. NO FLAMING. If you feel that you have been insulted in some way by
  463.     somebody, you have three options.
  464.      (a) Complain by netmail to the person concerned.
  465.      (b) Bring the matter to the moderator's notice - again by netmail.
  466.      (c) Ignore it. (the preferred option!)
  467.  
  468.  3. Person-person messages that are not of general interest to other
  469.     users are STRICTLY not permitted. Netmail these types of messages.
  470.  
  471.  4. When replying to messages try and do so "off-line" and quote some of
  472.     the message being replied to. However don't go overboard with
  473.     quoting. Quote just enough to enable the context of the reply to be
  474.     fully understood and in particular DO NOT INCLUDE PARTS OF THE TEAR
  475.     AND ORIGIN LINES.
  476.  
  477.  5. When replying to questions with code examples, test them where
  478.     possible by compiling and running them (or state that you have not
  479.     done this). If possible always quote manual references, text
  480.     references etc. If your code example contains inline code then it is
  481.     only fair that you FULLY comment such code so that users can
  482.     determine the validity or viability of that code BEFORE risking it
  483.     on their own machines/data.
  484.  
  485.  6. If replying to a question where you are disagreeing with the other
  486.     person's code or statement/s, support your viewpoint with working
  487.     code examples or valid text references. This will be more productive
  488.     than unsupported statements. If you are not prepared to do this then
  489.     don't reply in the first place!
  490.  
  491.  7. Do not ENTER or REPLY TO off-topic messages.
  492.     The subject matter is Pascal.  Discussions on religion, politics,
  493.     copyright, other programming languages and personal messages are 
  494.     OFF-TOPIC.  Any subject that is illegal or undesirable in a
  495.     responsible conference - eg discussion or tips on producing viruses or
  496.     how to illegally obtain access to information that the user is
  497.     unauthorised to obtain, is off-topic and will be severely dealt with.
  498.  
  499.     Sometimes messages from other conferences become linked into another
  500.     conference due to faulty software. Replying to, or commenting on, such
  501.     messages is not permitted.
  502.  
  503.     The main point is to use common sense.  Some light hearted banter can
  504.     relieve the formality and brighten up ones day but do not carry this to
  505.     the length where it becomes an extended thread.  The object of the echo
  506.     is to help, get help and enjoy communicating with like-minded people.
  507.  
  508.  8. No "thank-you" or "no content" or "rubbish" messages. Sysops spend a
  509.     great deal of time and money to enable the distribution of echoes
  510.     such as this. Please respect this and avoid messages such as "Thank
  511.     you. Just what I needed" or "I agree" etc. By observing this
  512.     etiquette you will be helping to ensure greater participation in the
  513.     future.
  514.  
  515.  9. All messages are to be in the English language and must be in PLAIN
  516.     TEXT.  No encryption of any kind is permissable as this is in direct
  517.     contravention of FidoNet policy.  This also means that binary file
  518.     transfer by conversion to asciiz is not allowed.
  519.  
  520. 10. Limited, low key, on-topic advertising is permitted. The key words
  521.     here are ON-TOPIC and LOW KEY. Please restrict any notices to a
  522.     "one-time" issue and keep it brief and informative with NO SALES
  523.     HYPE. Any notice must be of interest to the echo participants in
  524.     general. Therefore this excludes such items as job vacancies, BBS
  525.     ads, for sale notices and similar as this is an International echo.
  526.  
  527. 11. When seeking assistance -
  528.     a)  If Turbo Pascal is your language, place the cursor on the key
  529.         word and call the on-line help (Ctrl-F1 in the IDE) to see if
  530.         the answer may be there.
  531.     b)  Double check the manual to see if the answer is there.
  532.     c)  When writing the message include enough code to allow would-be
  533.         helpers to have a chance to determine what the problem might be.
  534.         If possible condense the problem into a tiny working example and
  535.         post that.
  536.     d)  This is a high volume echo so use a subject line in the message
  537.         that is likely to gain attention from the experts who are often
  538.         too busy to read every message.  "Help wanted" or similar is a
  539.         good way to be ignored. Something like "Exec procedure not
  540.         working" is better.
  541.     e)  Remember that a reply of "RTFM" is not considered or meant as an
  542.         insult. In fact it is considered a polite (in spite of the
  543.         connotations) way of reminding someone that the answer they seek
  544.         is in the manual.
  545.     f)  Remember also that your reply may come from anyone, of possibly
  546.         unknown skill level.  Don't be too upset if misled as it is
  547.         probably unintentional and will almost certainly be corrected by
  548.         another reader.
  549.  
  550. 12. When offering advice or help -
  551.     a)  Do so in a helpful, polite manner.  Don't be condescending - not
  552.         everybody may have your experience or skills.
  553.     b)  Refer to the page in the manual where the answer is if your
  554.         answer is "RTFM"!
  555.  
  556. 13. Messages should comply with the FidoNet message requirements. Origin
  557.     lines should not exceed 79 characters, tear lines must not exceed 25
  558.     characters and messages should not contain any "hi-bit" (characters
  559.     with an ascii code over 127) characters. No encrypted text is
  560.     permitted.  Messages are to be under 150 lines in length.
  561.  
  562. 14. Election of Moderator.  Under a normal situation, if the moderator
  563.     wishes to step aside, s/he will appoint a new moderator taking into
  564.     account the wishes of the regular users where possible.  In the event
  565.     of a moderator ceasing to participate in the echo for a period of
  566.     three months without prior notice being given of the absence, for
  567.     whatever reason, then the ZEC (1:1/201) will conduct, or nominate a
  568.     regular and senior echo participant to conduct, an election for a new
  569.     moderator.
  570.  
  571. Any suggestions re alterations to this message are welcome. Please make
  572. such suggestions by netmail.
  573.  
  574.  
  575.  
  576. --- TC-ED   v2.01  
  577.  * Origin: The Pilbara's Pascal Centre (+61 91 732930) (3:690/644)
  578.  * Tossed by SFToss v1.00b on 92/06/02  19:32:07
  579.  
  580. ▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄
  581.  
  582. Conference 4
  583. Date       06-02-92 00:45:27
  584. From       Trevor Carlsen
  585. To         John Meyers
  586. Subject    Telegard source code
  587.  
  588.  
  589.  
  590.  JM> I too am interested in getting the Telegard 2.7 source.
  591.  JM> Anyone have it?
  592.  
  593. This has nothing to do with the topic of this conference.  Please do not post
  594. such a message again.
  595.  
  596. Trevor Carlsen
  597. Moderator.
  598.  
  599. --- TC-ED   v2.01  
  600.  * Origin: The Pilbara's Pascal Centre (+61 91 732930) (3:690/644)
  601.  * Tossed by SFToss v1.00b on 92/06/02  19:32:07
  602.  
  603. ▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄
  604.  
  605. Conference 4
  606. Date       06-02-92 00:50:42
  607. From       Trevor Carlsen
  608. To         Jud Mccranie
  609. Subject    Re: Help - Reading Record
  610.  
  611.  
  612.  
  613.  TC> Did you receive my solution?
  614.  
  615.  JM> No, somehow I didn't.  It seems that the best thing will be
  616.  JM> to open as a file of char (or byte), jump over the heading,
  617.  JM> and then blockread the size of the records, or a multiple of
  618.  JM> the records, then typecast the block as the record type.
  619.  
  620. That would not work.  BlockRead only works on untyped files.  However if the
  621. file was untyped it would work. However there are better ways.  BTW in the
  622. above method why typecast?  If the buffer a record of the appropriate type
  623. (or an array of same in the case of the multiple read), no typecast is necessary
  624.  
  625.  
  626. In another message I have re-entered my original solution for you.
  627.  
  628. TeeCee
  629.  
  630. --- TC-ED   v2.01  
  631.  * Origin: The Pilbara's Pascal Centre (+61 91 732930) (3:690/644)
  632.  * Tossed by SFToss v1.00b on 92/06/02  19:32:07
  633.  
  634. ▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄
  635.  
  636. Conference 4
  637. Date       06-03-92 14:32:10
  638. From       Dj Murdoch
  639. To         Paul Doerwald
  640. Subject    Re: Message base formats (was: overlay f
  641.  
  642.   PD> Problem is that I'm complete C illiterate.  I'll be taking 
  643.  PD> a C high-school course in 2 years, but I really doubt 
  644.  PD> until then that I'd be learning C.  Is it well-documented 
  645.  PD> enough that I could understand it?
  646.  
  647. I don't know.  You'll have to take a look at it yourself.
  648.  
  649. --- Msg V3.2
  650.  * Origin: Murdoch's_Point  - -   (1:221/177.40)
  651.  * Tossed by SFToss v1.00b on 92/06/04  07:29:21
  652.  
  653. ▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄
  654.  
  655. Conference 4
  656. Date       06-03-92 14:36:57
  657. From       Dj Murdoch
  658. To         Scott Samet
  659. Subject    Re: TBufStream allocs
  660.  
  661.   SS> I'm curious where you find it documented that the heap 
  662.  SS> will never exceed the value specified?
  663.  
  664. That's in the second indexed reference to $M in the Programmer's Guide - p.
  665.  211 in my book.  
  666.  
  667. "The actual size of the heap depends on the minimum and maximum heap values,
  668. which can be set with the $M compiler directive.  Its size is guaranteed to
  669. be at least the minimum heap size and never more than the maximum heap size."
  670.  
  671.  SS> TP just plugs the $M values into the appropriate fields of 
  672.  SS> the EXE file header.  Right off the bat, it's rounded into 
  673.  SS> paragraphs, so unless you specify a multiple of 16, 
  674.  SS> there's going to be some difference.
  675.  
  676.  SS> It's up to DOS to actually allocate them memory, so 
  677.  SS> perhaps it's rounding to some coarser increment than 16.  
  678.  SS> TP could (but does not) also save the exact heap value in 
  679.  SS> a private location and use when initializing the heap variables.
  680.  
  681. Yes, I think you've got it right.  DOS (version 5 at least) allocates the
  682. number of 512 byte pages minus the header size plus the number of extra paragrap
  683. s specified in the .EXE header.  It ignores the "size mod 512" field.  The
  684. surprising thing is that the leftover part of the last page doesn't go to
  685. waste - TP seems to take it into account when it positions the stack.  
  686.  
  687. --- Msg V3.2
  688.  * Origin: Murdoch's_Point  - -   (1:221/177.40)
  689.  * Tossed by SFToss v1.00b on 92/06/04  07:29:21
  690.  
  691. ▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄
  692.  
  693. Conference 4
  694. Date       06-03-92 01:02:59
  695. From       Trevor Carlsen
  696. To         Shawn Osborn
  697. Subject    Re: Turbo 6
  698.  
  699.  
  700.  
  701.  SO> Mark, I've noticed many messages to/from you concerning TP5.5 & 6.0. I 
  702.  
  703.  SO> take it that you have tried both so maybe you can offer me some 
  704.  SO> advice.  I just bought Paradox 3.5, and the engine.  Right now I use 
  705.  
  706.  SO> TP5, but see that PD engine supports only TP5.5 & 6.  My question is: 
  707.  
  708.  SO> Becuase I will be writing database applications and want to write some 
  709.  
  710.  SO> in Pascal linking then thru the engin, which (in your opinion) is the 
  711.  
  712.  SO> one I should look at purchasing...
  713.  
  714. You do not have the luxury of a choice. TP6 is the only version being sold
  715. (unless some old stock is available somewhere).
  716.  
  717. TP6 is a very much superior compiler to TP5.5 in spite of opinions you may
  718. read to the contrary (which rarely state that they are opinions AND that they
  719. refer to the IDE and not the compiler).  I do not believe that there is a
  720. single feature of TP6 - the compiler - that is a step backwards from TP5.5
  721. and I doubt that anyone will point one out to you and there are several BIG
  722. improvements -
  723.   * BASM (a MAJOR addition)
  724.   * Extended syntax
  725.   * 286 code generation
  726.   * New heap management technique
  727.   
  728. TeeCee
  729.  
  730. --- TC-ED   v2.01  
  731.  * Origin: The Pilbara's Pascal Centre (+61 91 732930) (3:690/644)
  732.  * Tossed by SFToss v1.00b on 92/06/04  19:05:17
  733.  
  734. ▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄
  735.  
  736. Conference 4
  737. Date       06-04-92 02:06:53
  738. From       Trevor Carlsen
  739. To         Herb Brown
  740. Subject    Wiping Disks
  741.  
  742.  
  743.  
  744.  HB> Would it be safe to assume that all one needed to do to wipe
  745.  HB> the unused portion of a given disk by simply opening a file
  746.  HB> and writing to it till the disk was full then deleting that
  747.  HB> file?
  748.  
  749. I think you could safely make that assumption.  One caveat might be to determine
  750. what is the minimum allocation size on the disk and use that as the buffer
  751. size for your writes.
  752.  
  753. TeeCee
  754.  
  755. --- TC-ED   v2.01  
  756.  * Origin: The Pilbara's Pascal Centre (+61 91 732930) (3:690/644)
  757.  * Tossed by SFToss v1.00b on 92/06/04  19:05:17
  758.  
  759. ▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄
  760.  
  761. Conference 4
  762. Date       06-03-92 18:21:16
  763. From       Dj Murdoch
  764. To         Dennis Menard
  765. Subject    Re: EXEC and ASSIGN
  766.  
  767.   DM> When I issue the command:
  768.  
  769.  DM>     exec('c:\command.com', 'dothis');
  770.  
  771.  DM> what results is a "Bad COMMAND search directory" error.  
  772.  DM> What does this mean, and how can I correct it?  
  773.  DM> COMMAND.COM exists where I have said it does.
  774.  
  775. The command being sent to command.com has to have a "/c" in front, or command.co
  776.  thinks you're specifying the directory to reload from.  It's also a good
  777. idea to use the COMSPEC environment variable rather than relying on finding
  778. command.com in c:\.  So, instead of your line, try:
  779.  
  780.   exec(getenv('comspec'),'/c dothis');
  781.  
  782.  
  783.  
  784. --- Msg V3.2
  785.  * Origin: Murdoch's_Point  - -   (1:221/177.40)
  786.  * Tossed by SFToss v1.00b on 92/06/05  14:22:39
  787.  
  788. ▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄
  789.  
  790. Conference 4
  791. Date       06-03-92 18:24:17
  792. From       Dj Murdoch
  793. To         Herb Brown
  794. Subject    Re: Wiping Disks
  795.  
  796.   HB> Would it be safe to assume that all one needed to do to 
  797.  HB> wipe the unused portion of a given disk by simply opening 
  798.  HB> a file and writing to it till the disk was full then 
  799.  HB> deleting that file?   I want to duplicate what Norton's 
  800.  HB> wipeinfo program does, in a sense.
  801.  
  802. That'll get most of it, but you'll miss some things:
  803.  
  804. Filenames of erased files will still be sitting in the directories.  If you
  805. had subdirectories, they may be unnecessarily large; DOS grows them when you
  806. add new files, but never shrinks them.
  807.  
  808. Tails of old files will still be there.  If you have a few files on your disk,
  809. the tails of those may contain old information, as well as the tail of the
  810. one you're writing.  
  811.  
  812. If the user has a cache that delays writes, it's conceivable that it would
  813. be smart enough never to write your big file to disk at all - but that seems
  814. pretty unlikely, since caches usually work at the BIOS level, not the DOS
  815. level.
  816.  
  817. --- Msg V3.2
  818.  * Origin: Murdoch's_Point  - -   (1:221/177.40)
  819.  * Tossed by SFToss v1.00b on 92/06/05  14:22:39
  820.  
  821. ▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄
  822.  
  823. Conference 4
  824. Date       06-04-92 05:58:13
  825. From       Dj Murdoch
  826. To         Jud Mccranie
  827. Subject    Re: Reading In Boot-Secto
  828.  
  829.   DM> Yes, there weren't any serial numbers before 4.0.  I don't know
  830.  DM> what sort of error you'd get if you called this service on an
  831.  DM> old version; it's probably safer to check the DOS version
  832.  DM> before you try.
  833.  
  834.  JM> On the disks formated with 3.3 that I looked at, the area that later
  835.  JM> --- 
  836.  
  837. That's all that made it out - could you try again?  Thanks.
  838.  
  839. --- Msg V3.2
  840.  * Origin: Murdoch's_Point  - -   (1:221/177.40)
  841.  * Tossed by SFToss v1.00b on 92/06/05  14:22:39
  842.  
  843. ▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄
  844.  
  845. Conference 4
  846. Date       06-04-92 06:21:13
  847. From       Dj Murdoch
  848. To         Jud Mccranie
  849. Subject    Re: Tp 6 Exe Slow?
  850.  
  851.   JM> I tested two programs, one was
  852.  JM> non-recursive and the TP 6 EXE was faster.  The other was recursive,
  853.  JM> and the TP 5.5 EXE was faster.  I have just tested another recursive
  854.  JM> program, and the results were the same - the TP 5.5 EXE is about 10%
  855.  JM> faster than the 6.0 EXE, and G+ makes no measurable difference.
  856.  
  857.  JM> So, it seems that recursion is much slower in TP 6.0.  Can anyone
  858.  JM> shed any light on this?
  859.  
  860. I don't think it's recursion.  The program below (a bad implementation of
  861. a Fibonacci function) spends almost all of its time doing recursive calls,
  862. and seems to be almost identical in execution speed in 5.5 or 6.0 with the
  863. same compiler options (well, as close as I could get).
  864.  
  865.  JM> Someone wanted to see my program that demoed the difference, and I
  866.  JM> can send a copy of this one on disk (the source is not that big, but
  867.  JM> it has a large data file with it).  Or I can zip it up and let someone
  868.  JM> freq it or I can shorten the data file and get the source and data in
  869.  JM> about 5 or 6 messages, if someone wants to see it.
  870.  
  871. Try instead to distill out the pure elements of the program.  For example,
  872. the program below spends a ton of time on recursive calls, and doesn't show
  873. the difference.  If you can hit on whatever it is that's faster in 5.5 than
  874. 6.0, and write a program that does nothing else, you should get a clear demonstr
  875. tion.
  876.  
  877. BTW, as people have said, the TP 6.0 .EXE file is bigger than the TP 5.5 .EXE:
  878.  3940 bytes versus 3843.  It's mostly because the included part of the SYSTEM
  879. unit is bigger; I'm not sure what has changed.  The other differences are
  880. that the Fib function is one byte smaller in 6.0 and the main body is a few
  881. bytes bigger, because it does a stack check at the beginning.
  882.  
  883.   {$A+,B-,D+,E+,F-,I+,L+,N-,O-,R-,S+,V+}
  884.   {$M 16384,0,655360}
  885.  
  886.   function fib(i:integer):integer;
  887.   begin
  888.     case i of
  889.       0,1 : fib := i;
  890.       else  fib := fib(i-2) + fib(i-1);
  891.     end;
  892.   end;
  893.  
  894.   var
  895.     i : integer;
  896.   begin
  897.     for i:=1 to 30 do
  898.       writeln(i:5,fib(i):8);
  899.   end.
  900.  
  901. This takes 25 seconds to execute, on a 486-33 under Desqview as the only active
  902. window.
  903.  
  904. --- Msg V3.2
  905.  * Origin: Murdoch's_Point  - -   (1:221/177.40)
  906.  * Tossed by SFToss v1.00b on 92/06/05  14:22:39
  907.  
  908. ▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄
  909.  
  910. Conference 4
  911. Date       06-05-92 01:14:24
  912. From       Trevor Carlsen
  913. To         Alvin Lee
  914. Subject    Searching for a certain string in text f
  915.  
  916.  
  917.  
  918.  AL> I was just wondering how to search for specific strings in a
  919.  AL> text file. I've heard that you use the function POS, but I
  920.  AL> would like an example of how you would use it.  Anyone
  921.  AL> know??  Thanx in advance.
  922.  
  923. Providing no line exceeds 255 characters and that the specific string cannot
  924. span lines here is a solution.
  925.  
  926. function Search(var f: text; SearchStr: string): integer;
  927.   { Returns the line number in the file that the Search string is found }
  928.   { in.  If not found returns zero.  If I/O error occurs returns a minus}
  929.   { value which coresponds to the line number where the I/O error was.  }
  930.  
  931. var
  932.   found,
  933.   IOErrror : boolean;
  934.   st       : string;
  935.   line     : integer;
  936. begin
  937.   line     := 0;
  938.   found    := false;
  939.   IOError  := false;
  940.   while (not found) and (not IOError) and (not eof(f)) do begin
  941.     {$I-} readln(f,st); {$I+}
  942.     IOError := IOResult <> 0;
  943.     inc(line);
  944.     found   := pos(SearchStr,st) <> 0;
  945.   end;
  946.   if IOError then
  947.     Search := 0 - line
  948.   else
  949.     Search := line * ord(found);
  950. end;
  951.  
  952. TeeCee
  953.  
  954.  
  955. --- TC-ED   v2.01  
  956.  * Origin: The Pilbara's Pascal Centre (+61 91 732930) (3:690/644)
  957.  * Tossed by SFToss v1.00b on 92/06/05  14:22:41
  958.  
  959. ▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄
  960.  
  961. Conference 4
  962. Date       06-05-92 01:29:02
  963. From       Trevor Carlsen
  964. To         Jud Mccranie
  965. Subject    Tp 6 Exe Slow?
  966.  
  967.  
  968.  
  969.  JM> Someone wanted to see my program that demoed the difference,
  970.  JM> and I can send a copy of this one on disk (the source is not
  971.  JM> that big, but it has a large data file with it).  Or I can
  972.  JM> zip it up and let someone freq it or I can shorten the data
  973.  JM> file...
  974.  
  975. Shorten the data, Zip it, name it, tell me where to get it and what its name is.
  976.  
  977.  
  978. TeeCee
  979.  
  980. --- TC-ED   v2.01  
  981.  * Origin: The Pilbara's Pascal Centre (+61 91 732930) (3:690/644)
  982.  * Tossed by SFToss v1.00b on 92/06/05  14:22:41
  983.  
  984. ▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄
  985.  
  986. Conference 4
  987. Date       06-05-92 17:47:00
  988. From       Norbert Igl
  989. To         Gerald Gutierrez
  990. Subject    Hex<>Dec
  991.  
  992.  
  993.  
  994.  
  995.  >> Thanks for the help.  Does that code convert back to decimal too?  Or
  996.  >> just from decimal to hex?
  997.  > I've never had the need to convert hex back into decimal .. sorry. 8)
  998.  > I don't expect it to be too difficult however. Basic procedure would
  999.  
  1000.  Hi...[BIG GRIN]...if anything else fails, read the manual... =(;-)
  1001.  
  1002. Var
  1003.    HexStr : String;
  1004.    DecVal : LongInt;
  1005.    NumErr : Integer;
  1006. begin
  1007.    HexStr := 'FFFF';
  1008.    Val('$'+HexStr, DecVal, NumErr );
  1009.    Writeln(' VAL() converted : $',HexStr,' to dec : ', DecVal );
  1010. end.
  1011.     Bye from Germany, Norbert
  1012.  
  1013. --- FD 2.02/FastEcho
  1014.  * Origin: STOP READING! You're leaving the MSG-sector (2:241/5300.3)
  1015.  * Tossed by SFToss v1.00b on 92/06/06  07:53:23
  1016.  
  1017. ▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄
  1018.  
  1019. Conference 4
  1020. Date       06-06-92 08:41:27
  1021. From       Trevor Carlsen
  1022. To         Chris Kelling
  1023. Subject    Re: A few Questions...
  1024.  
  1025.  
  1026.  
  1027.  CK> The main difference between the two is the way the memory is
  1028.  CK> used. The Stack is a first in last out (FILO), or the first
  1029.  CK> element is going to end up being the last element used.
  1030.  
  1031. This is correct but I prefer to look at it as LIFO as that seems to make it
  1032. easier to understand.
  1033.  
  1034.  CK> The Heap is just the oppisite.  It is First in First out
  1035.  CK> (FIFO).  This is where your program stores the statements,
  1036.  CK> where as the Stack is where the variable vaules (among other
  1037.  CK> things like pointers for program control) are stored.
  1038.  
  1039. And this is just plain wrong!  The heap is all of that memory allocated to
  1040. the program by DOS but not allocated for code, data or stack.  The heap is
  1041. used to dynamically store information and can be allocated/deallocated in
  1042. any order at all.  The heap manager controls the allocation of heap resources
  1043. on a "First Fit" basis. The programmer also has the ability to allocate heap
  1044. space as s/he sees fit.
  1045.  
  1046. TeeCee
  1047.  
  1048. --- TC-ED   v2.01  
  1049.  * Origin: The Pilbara's Pascal Centre (+61 91 732930) (3:690/644)
  1050.  * Tossed by SFToss v1.00b on 92/06/06  13:09:53
  1051.  
  1052. ▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄
  1053.  
  1054. Conference 4
  1055. Date       06-06-92 09:42:18
  1056. From       Trevor Carlsen
  1057. To         Gerald Gutierrez
  1058. Subject    Mod Struct [1/2]
  1059.  
  1060.  
  1061.  
  1062.  GG> Protracker 1.1B Song/Module Format:
  1063.  
  1064. For some time now we have seen the number of messages on the technical aspects
  1065. of the SoundBlaster and various video systems and with no direct relationship
  1066. to Pascal becoming more frequent.  I have ignored them in the hope that they
  1067. would go away.
  1068.  
  1069. This latest couple of messages are the straw that broke the camel's back :-)
  1070.  
  1071. In future all messages re the SB, MOD files, video technicals etc that are
  1072. not of GENERAL interest and have no DIRECT Pascal link are to be regarded
  1073. as off-topic in this echo.
  1074.  
  1075. Trevor Carlsen
  1076. Moderator.
  1077.  
  1078. --- TC-ED   v2.01  
  1079.  * Origin: The Pilbara's Pascal Centre (+61 91 732930) (3:690/644)
  1080.  * Tossed by SFToss v1.00b on 92/06/06  13:09:53
  1081.  
  1082. ▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄
  1083.  
  1084. Conference 4
  1085. Date       06-06-92 17:46:25
  1086. From       Trevor Carlsen
  1087. To         Jud Mccranie
  1088. Subject    Re: Topics..
  1089.  
  1090.  
  1091.  
  1092.  JM> Pascal Lessons is for beginners and this one is for more advanced
  1093.  JM> programmers.  General, basic questions should be asked on "lessons".
  1094.  
  1095. This is precisely the impression I like to avoid giving. This echo is for
  1096. ALL levels of Pascal discussion.
  1097.  
  1098. TeeCee
  1099.  
  1100. --- TC-ED   v2.01  
  1101.  * Origin: The Pilbara's Pascal Centre (+61 91 732930) (3:690/644)
  1102.  * Tossed by SFToss v1.00b on 92/06/06  13:09:53
  1103.  
  1104. ▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄
  1105.  
  1106. Conference 4
  1107. Date       06-06-92 11:21:39
  1108. From       Trevor Carlsen
  1109. To         Jud Mccranie
  1110. Subject    Re: Why I Like Tp 5.5 Ide
  1111.  
  1112.  
  1113.  
  1114.  PF> Could you please list some for me, I'm using 6.0 and my
  1115.  PF> interest lies in being able to offer stable applications to my
  1116.  PF> clients. If 6.0 has some flaws, I want to know what they are
  1117.  PF> and the workarounds !
  1118.  
  1119.  JM> ... The problems are with the 6.0 IDE. It is very hard to
  1120.  JM> use, especially changing the search and replace/find
  1121.  JM> options, for instance. The menu isn't sticky where it should
  1122.  JM> be. The IDE is slow on a 386 with 8 megs of RAM and a fast
  1123.  JM> HD.  (50 MHz 486 may be fast enough.)  There are anoying
  1124.  JM> flashes on the screen when changing from one thing to
  1125.  JM> another.  Some nice features in 5.x are missing in 6.0 IDE.
  1126.  JM> Keys don't work the way they should in the 6.0 IDE.  All in
  1127.  JM> all, the 6.0 IDE is very frustrating to use (if you are used
  1128.  JM> to a good IDE like 4.0 - 5.5).
  1129.  
  1130. Jud, you do yourself absolutely no justice by continuing to harp on about
  1131. your pet hate (the TP6 IDE) in this way.  By all means express your opinion
  1132. to those who ask, but stress that it is an opinion and not necessarily fact.
  1133.  There are a big majority out there who would disagree with you and others
  1134. who would only partly agree.
  1135.  
  1136. *IMHO*, for a "professional" programmer to describe the TP4/5 IDEs as "good"
  1137. is very close to being a joke.  They just don't come even close.  They are
  1138. easier to use than the TP6 IDE (at first) but much less powerful.
  1139.  
  1140. *IMHO* the TP6 IDE is very much closer to being a professional grade environment
  1141. than are its predecessors but still has some considerable way to go yet. 
  1142. It is extraordinarily hard to use in some areas and is nowhere near as intuitive
  1143. as the TP5 IDE. It also takes a long time to set up so that it works the way
  1144. you want it to.  I suspect that this may be your real complaint. There are
  1145. many better, far more productive environments available on the market.
  1146.  
  1147. TeeCee
  1148.  
  1149. --- TC-ED   v2.01  
  1150.  * Origin: The Pilbara's Pascal Centre (+61 91 732930) (3:690/644)
  1151.  * Tossed by SFToss v1.00b on 92/06/06  13:09:53
  1152.  
  1153. ▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄
  1154.  
  1155. Conference 4
  1156. Date       06-06-92 09:20:06
  1157. From       Trevor Carlsen
  1158. To         Peter Beeftink
  1159. Subject    Writing directly to disk sectors.
  1160.  
  1161.  
  1162.  
  1163.  PB> Would anyone know how to write a function which:
  1164.  PB> 1) finds the disk sectors occupied by a file?
  1165.  PB> 2) read/write to absolute disk sectors?
  1166.  
  1167.  PB> The idea is to be capable of writing some bytes in the slack
  1168.  PB> space of a file which is not included when the file is
  1169.  PB> copied to another location.
  1170.  
  1171. I am always reluctant to post code here that will do direct sector writes.
  1172. I take the view that if you need that badly enough and don't have the necessary
  1173. skills or experience then you can purchase a professional library that will
  1174. include that capbility (Object or Turbo Professional).  So that is what I
  1175. would recommend to you.
  1176.  
  1177. However in this case the problem as stated can easily be solved without resortin
  1178.  to direct sector read/writes.
  1179.  
  1180. Open the file as untyped, save the length, seek to eof, write your information
  1181. to the end, and close the file.  Reopen it, and truncate it to the old length.
  1182.  The information written will still be there on the disk in the slack space.
  1183.  
  1184. To read that information, open the file, write a byte to an offset past the
  1185. extra information and then seek  back and read the information. Close, reopen
  1186. and truncate to restore things back again.
  1187.  
  1188. TeeCee
  1189.  
  1190.  
  1191.  
  1192. --- TC-ED   v2.01  
  1193.  * Origin: The Pilbara's Pascal Centre (+61 91 732930) (3:690/644)
  1194.  * Tossed by SFToss v1.00b on 92/06/06  13:09:53
  1195.